1. Field of the Invention
This invention relates to file servers and more particularly relates to preserving the integrity of connection/position data while reinitializing serialization data in a file server in response to a serialization failure.
2. Description of the Related Art
Serialization of a plurality of data access requests can be extremely complicated for data storage devices that are shared among multiple-processor file system servers. Serialization of the data access requests involves defining which applications are connected to which storage devices, or portions thereof, and what kind of access is provided for each application. For example, some applications are given exclusive access rights for certain write operations, while others may not receive exclusive access. Also, some applications may receive shared access rights for certain read operations on the shared data storage devices. By defining which applications are allowed which type of access at which times, the file system servers are able to prevent many data operation errors that would otherwise occur.
However, serialization techniques are not perfect and a serialization implementation may fail. A serialization failure may occur when read or write access to a requested data file or directory is not made available to a requesting application. For example, a serialization failure may occur when two applications are requesting data access rights to data that is exclusively assigned to the other application.
FIG. 1a shows one example of an application environment 10 in which a serialization conflict might occur. In particular, the illustrated application environment 10 includes a first application 12 and a second application 14. The first application 12 has exclusive rights (as shown by the solid arrow 16) to a first data file 18. Likewise, the second application 14 has exclusive rights (as shown by the solid arrow 20) to a second data file 22.
FIG. 1a also shows the first application 12 requesting access rights (as shown by the dashed arrow 24) to the second data file 22. Likewise the second application 14 may request access rights (as shown by the dashed arrow 26) to the first data file 22. In this case, a serialization “deadlock” failure occurs when neither the first application 12 nor the second application 14 can progress until the requested access rights are granted, but the requested access rights cannot be granted because the requested data files 18, 22 are already in use by the non-requesting applications 12, 14. When this type of serialization failure occurs, the file system server (not shown) may become nonresponsive and thereby unavailable because the applications 12, 14 continue to hold onto their existing access rights while requesting the additional access rights.
Although an internal serialization failure, by itself, does not compromise either the integrity of the data stored in the data files 18, 22 or the run-time states of the in-flight applications 12, 14, such a serialization failure can have drastic effects on the file system server. For instance, a serious serialization failure may occur where the file system is central to an operating system, such as when the ability to load programs from a file system is necessary for basic operating system functions. Furthermore, serialization failures can result in operating system outages, which can cause the failure of all in-flight application processing, including processing that is not directly related to the corresponding file system. Additionally, serialization failures may lead to excessive costs due to file system server downtime that impacts business-critical applications.
FIG. 1a also shows the first application 12 requesting access fights (as shown by the dashed arrow 24) to the second data file 22. Likewise the second application 14 may request access fights (as shown by the dashed avow 26) to the first data file 18. In this case, a serialization “deadlock” failure occurs when neither the first application 12 nor the second application 14 can progress until the requested access rights are granted, but the requested access rights cannot be granted because the requested data files 18, 22 are already in use by the non-requesting applications 12, 14. When this type of serialization failure occurs, the file system server (not shown) may become nonresponsive and thereby unavailable because the applications 12, 14 continue to hold onto their existing access rights while requesting the additional access rights.
Because conventional serialization management schemes typically solve serialization failures by restarting the file server, conventional techniques also fail to address how to maintain connection/position data integrity during the reinitialization of the file server. Rather, conventional serialization management schemes allow open file connections and other resource connections to fail while the file server is down. In other words, all open resource connections, whether for directories, sub-directories, directory entries, files, or other resources, are lost when the file server becomes nonresponsive.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method for automatically preserving connection/position data integrity during reinitialization of serialization data after a file system serialization failure. Beneficially, such an apparatus, system, and method maintain the connection/position data in a stable state so that it may be used for reinitialization of file system serialization information. Additionally, such an apparatus, system, and method would be advantageous over conventional systems and methods by allowing such connection/position data to be used to rebuild the serialization information after reinitialization.